Referring firstly to the hierarchy 10 shown in FIG. 1, a “system” 12 is an organized assembly of components and the relationships between these components. The components of a system may include other systems, and so the term “system” also encompasses the notion of a system of systems.
An “information system” 14 is a type of system, whether automated or manual, consisting of people, tools, methods, and information organized to collect, validate, process, transmit, and disseminate data that represent information.
An “enterprise” is a company, business, organization, or other purposeful endeavor. Here, the word is extended to include projects, and joint ventures involving multiple enterprises.
One type of information system is an “enterprise resource planning system” 16 (ERP system). ERP systems 16 are designed to serve an enterprise by integrating the management of some type of resource. Examples are financial management systems 18 (managing financial resources), human resources management systems 20 (managing people within the enterprise), supply chain management systems 22 (managing goods and services suppliers as a resource) and customer relationship management systems 24 (managing customers as a resource).
“Integration” refers to the bringing together of a plurality of things. Here, it refers to the bringing together of a plurality of system components. It is the most important component of the architecture of systems. The bringing together of things gives rise to a need for a plurality of components that are shared, and so do not belong exclusively to any one of the integrated systems. Integration components include, but are not limited to, interfaces, standards, frameworks, patterns, methods, processes, hardware, system software, communications networks, and management of systems.
Typically, an enterprise will have multiple information systems 14, including multiple ERP systems 16. These systems do not exist in isolation. They share resources, such as computer and communications resources. They share data, such as payroll data that is linked to data about people in the human resources system and data about money in the financial system. They also share people and processes involved in the management of shared services and facilities. All of this sharing requires integration. This gives rise to the idea that there is an implicit enterprise-wide system that manages the integration of both deployed information systems and their supporting deployed metasystems.
The current approach to the management of systems relies primarily on the use of the static artifacts that collectively represent a metasystem. Because the artifacts are static, the metasystems that manage them are here termed “static metasystems”. Further, because the current approach to the management of systems does not distinguish integration systems, integration is handled in a piecemeal manner, driven by projects that are generally funded to deliver a specific business outcome.
A “project” is a time-, scope- and budget-constrained activity undertaken by an enterprise to achieve some business purpose. Unless directed through enterprise-level architecture, it would be rare for a project to divert resources from delivery to its precise scope constraint so as to make its delivered artifacts more amenable to integration.
In current practice, coordination between static metasystems and the systems they manage is poor, being implicit or incidental. Coordination between integration systems and their corresponding deployed information systems is also poor.
A static metasystem contains static artifacts that are used primarily to specify and describe some aspect of the management of a system at a point in time. However, in a static metasystem, with the narrow exception of some artifacts such as diagrams drawn to the Unified Modified Language (UML) standard published by the Object Management Group Consortium (www.omg.org), and their supporting tools that may generate computer code, the artifacts are not dynamically inter-linked. That is to say, the relationship between artifacts is established tacitly—by convention.
The generic flow of current approaches is illustrated in FIG. 7A, which represents an abstraction of a structure 700 used in the production of a static deployed information system 707. A static integration metasystem 704 defines enterprise level standards, methods, processes and possibly architecture for the enterprise as a whole, in the form of static artifacts. The static integration metasystem 704 also establishes processes for audit or intervention and also coordination or regulations. The static integration metasystem 704 includes multiple tools which produce static artifacts, and are poorly integrated. The static integration metasystem 704 uses a static integration repository 701 that contains static artifacts.
At the deployed level, the static integration metasystem 704 and static integration repository 701 are used in the establishment of a static deployed information system 707. For example, the static integration metasystem 704 establishes standards, which in turn are meant to be adhered to at lower levels in the enterprise, using static deployed metasystems 705, to build systems for delivery to internal or external or nominal clients. The static deployed metasystem 705 may also operate static deployed information systems 707 for clients 703, and should follow integration standards supplied from the static integration metasystem 704. The static deployed metasystem 705 includes multiple known tools which are in general designed to produce static artifacts. They are also in general not integrated beyond the capability to support simple cut and paste. The static deployed metasystem 705 is used to produce a static deployed repository 702, which includes static artifacts for static deployed information systems 707. Compliance with policies and standards is effected through means such as process discipline, supported by audit and procurement processes.
The static integration system 706 is a shared environment that provides services to one or more deployed information systems 707. It contains shared known infrastructure including, but not limited to, shared servers; communications networks; and services such as management of the shared infrastructure; and component services that are exposed for use by one or more static deployed information systems 707. The static integration system is managed by the static integration metasystem 704.
A “client” 703 is a person representing the enterprise who understands the business need for the deployed information system. A “nominal client” is a representative of a presumed set of clients, as may occur in an entrepreneurial endeavor to produce a system for licensing to the public. Here, the term “client” is taken to include a nominal client.
A client 703 defines requirements for a deployed information system, which are recorded in the static deployed repository 702, and used to manage the static deployed information system 707. The resulting static deployed information system 707 is used by the client 703, or by purchasers of licenses for a system built for sale to the public, but typically contains few tools. To the extent that metasystem tools are packaged with the static deployed information system 707, these tools are static and not integrated.
In the military context, systems are categorized as mission systems and support systems. Mission systems are analogous to static deployed information systems 707. Support systems are analogous to static deployed metasystems 705.
The abstract current practice process representation in FIG. 7A is made more concrete in FIG. 7B, using the example of a static financial management system 714. A known instantiation of such a system is SAP™ from SAP AG, Waldorf, Germany (www.sap.com). FIG. 7B has the same structure as FIG. 7A, but replaces the abstract names in FIG. 7A with names that may be used in an instantiation.
FIG. 7B includes a financial management system 714, being an instance of a static deployed information system 707, and an enterprise environment, being an instance of a static integration system 706. It also includes an enterprise support system 711 that is an instance of a static integration system 704, and an enterprise repository 708 that is an instance of a static integration repository 701. In current practice, the enterprise support system 711 and the enterprise repository 708 are unlikely to be realized as cohesive or enduring units, but exist rather as composites of elements distributed throughout the enterprise.
FIG. 7B also depicts a financial management support system 712, being an instance of a static deployed metasystem 705 and a financial management repository 709 being an instance of a static deployed repository 702. In current practice, a financial management support system may be realized from time to time, embodied in projects that implement or upgrade a financial management system 714. In current practice, a financial management repository 709 is unlikely to be realized as a cohesive unit.
The current approach suffers the deficiencies that it does not formally recognize the existence of metasystems on the one hand; or the hierarchy of integration and deployed information systems on the other. The result is that metasystems are not managed as systems, and can become incoherent and largely unmanaged collections of static artifacts. Integration between systems occurs through poorly coordinated interfaces, usually point to point interfaces between pairs of systems.
The described approach results in a situation where metasystem artifacts are routinely inconsistent with each other, and are also inconsistent with the static deployed information system 707 that they were meant to manage. Manual or partly-automated techniques such as desk-checking, version control, and static configuration management represent attempts to alleviate the problem, but they depend upon conscientious conformance to a human process. The relationships of components within the metasystem are frequently either tacit or obscure, such as where relationships are explained in multiple large static textual documents or static diagrams. It is usually a requirement for quality assurance to check the fact that selected components of a metasystem have been produced so as to conform to a requirement of a project for delivery against a contracted set of artifacts. However, it is seldom the case that quality assurance extends to checking the detail of whether the metasystem is complete, accurate or sufficient. Routinely, even artifacts at different meta-levels in the same domain, e.g. logical and physical architectures, are connected to each other only tacitly—by convention.
The construction of static systems results in a situation where change is treated inappropriately as a departure from normal operation. Change is more correctly viewed as the continuous state of information systems. After the static deployed information system 707 has commenced productive operation, changes will occur constantly in business, technology or other environments, and many of these changes will necessitate change to the system. Environmental change may affect the static integration system 706, and lead to cascading change requirements in multiple static deployed information systems.
Environmental change will often require that the existing static deployed information system 707 should be reviewed to determine whether it remains the appropriate solution for current circumstances. In a static system, such review requires the client 703 or the metasystem user 505 to go to the static deployed repository 702 and the static integration repository 701 in order to understand the detail of the static deployed information system 707, and its use of the static integration system 706. Static repositories will contain numerous artifacts, built at different times for different purposes, and usually physically stored across multiple locations. The review must assess the current situation in the environment, and also the new environment, especially business and technology environments. The review must then identify business and technology options for adaptation to any change and compare these options for perceived effectiveness. After comparing the effectiveness of different options, the review must select the most appropriate option for response to the change.
If the selected option is not to maintain the status quo, a change to the solution is required and the organization must design a new solution and a transition to the new solution. The new business and/or technology solutions must then be built, and change management invoked to deploy the new information system. These redesign and change management tasks would be performed by different people using diverse tools, and would require use of static artifacts that describe different aspects of the static deployed information system 707, with no promise of consistency or accuracy. The results of the work would be captured in a similar array of artifacts, with similar qualitative properties.
Given a static integration system, there is a high probability that multiple projects, or multiple people within any one project, would undertake similar work, leading to unnecessary duplications, overlaps and inconsistent usage of information. There is also a strong probability that there will be gaps, where some change requirements are not recognized as belonging to any project, and so are not addressed by any. The net effect is the changed systems will require workarounds such as manual processes for reconciliation of data. This gives rise to ongoing operational issues around integration. This is a common situation in enterprises, even in ERP systems and core business systems. Gaps, overlaps and workarounds draw the attention of management auditors.
Current tools, methods, and practice are specialized towards this static view of both metasystems and systems, and are generally limited in scope to either technology or human processes.
A partial departure from the static view of the world is the UML standard (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML), which addresses both process and parts of technology. However, the UML standard is not designed to be part of a dynamic system, or a dynamic metasystem. The same is true of current high-end Enterprise Architecture systems such as the PTech Enterprise Framework™ from Plains Technology Inc, of Fargo N. Dak., and the Popkin System Architect™ available from Telelogic North America Inc, of Irvine, Calif. These tools, whilst comprehensive within a static scope, are not intended for dynamic use throughout the life of a system, nor for deployment to day-to-day administrators and managers.
The Visio™ tool supplied by Microsoft (www.microsoft.com) provides for the inclusion of some logic behind graphical objects, and can generate database definition statements and emit some computer code from a UML diagram. However, Visio's primary focus is upon the creation of two-dimensional diagrams, and the tool does not support management of a dynamic system.
There are several published frameworks for enterprise architecture (e.g. John Zachman's Framework for Information Systems Architecture (www.zifa.com), the Open Group's Architecture Framework (TOGAF, www.opengroup.org/togaf/) and the C4ISR architecture framework of the US Department of Defense www.fas.org/irp/program/core/c4isr.htm) which define views of the data to be included in artifacts. In addition, many organizations define their own frameworks, which may be derivations of one or more of the published frameworks.
The frameworks define content, and establish rules for connection between artifacts. However, the frameworks take a static view of artifacts. The consequence of reliance on static practices and work-products is unnecessarily high costs, delays and risks that are incurred in workarounds throughout the life of a static system. These costs and risks arise where manual audit becomes necessary to validate artifacts, and where edit or replacement become necessary for them to be reliably usable. The consequences of changing a system based on false premises may include leaving the changed system in a non-functional state.
A deployed dynamic information system, method for making a change to an information system formed as a deployed information system and a deployed metasystem, a persistent dynamic repository, and a dynamic information system software tools also are disclosed. Other aspects are disclosed.